Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

Should we consider the implementation of "an older version of the specification with inconsistent behavior" as a partial implementation?

Forgot to cc @Elchi3 or @ddbeck.

Should we consider the implementation of "an older version of the specification with inconsistent behavior" as a partial implementation?

@caugner There was already some discussion of that in #29676 (comment)

FWIW IMO no, on the basis that it wasn't a partial implementation: it was a full implementation of a buggy spec. I quite like the current approach. I'll leave for you lot to resolve how you want it though.

Should we consider the implementation of "an older version of the specification with inconsistent behavior" as a partial implementation?

@caugner There was already some discussion of that in #29676 (comment)

Thanks for the reminder. But doesn't Chrome 150 (stable) also implement the new version? If it was just Firefox 153 (beta), we might have wanted to wait, but now that both implementing engines implement the new version, we should be able to go ahead and mark the old version as partial (as suggested by Daniel in the linked comment). Technically, this reverts Firefox support from Stable to Beta, but I would think that's okay for 2 weeks until the 153 stable release.

... But doesn't Chrome 150 (stable) also implement the new version? If it was just Firefox 153 (beta), we might have wanted to wait, but now that both implementing engines implement the new version, we should be able to go ahead and mark the old version as partial (as suggested by Daniel in the linked comment). Technically, this reverts Firefox support from Stable to Beta, but I would think that's okay for 2 weeks until the 153 stable release.

Yes it does https://developer.chrome.com/release-notes/150?hl=en#popoverhint_behavior_changes

Fixed as I think you wanted ("treat an older version of the specification with inconsistent behavior as a partial implementation")

FWIW I would have said "that is inconsistent with how BCD works". Seems like there is support for the idea in that thread though, and I don't feel strongly.

We discussed this on today's BCD call and we agreed to approve and merge. We also thought @hamishwillee deserved a response to:

I would have said "that is inconsistent with how BCD works"

Yes, I can see how this might appear. My elaboration here is that BCD doesn't accommodate situations like this one very well, where we effectively have two distinct behaviors that happen to share the same name. It would be easy to handle something like popover="hintv2" in BCD without partials (or subfeatures). But our schema doesn't let us represent two different lineages of identically named features. Here, partial is a little bit of a hack to avoid saying to developers that the two implementations are successively compatible, which is what would be implied by a feature with a note (but no partial) or implied on the parent of a behavioral subfeature. I hope this helps explain the situation better.

In any case, thank you Hamish!

Fwiw I agree with the use of 'partial' here, even though it isn't 'pure' by definition. This was a weird case because the spec was internally inconsistent, leading to what felt like buggy behaviour.

I guess we could have added a bunch of entries for the behaviour changes, but they'd have been very wordy like "Maintains 'hint' behaviour when nested within an 'auto' popover", and had those as not-supported in the earlier versions, but I think it's simpler to just say the old version was weird/broken.